Software Vault: The Diamond Collection/The Diamond Collection (Software Vault)(Digital Impact).ISO/cdr16/tc14_459.zip/TC14-459.TXT

Text File | 1995-01-22 | 8KB | 186 lines

From: Anthony Chor <[e-mail]>
Date: Mon, 19 Dec 94 15:19:24 PST
Subject: Re: Caller ID With Call Waiting


Jason White writes:

> It was also mentioned that Caller-ID would work with call-waiting;
> if you're on the phone and get the call-waiting beep, you'd also see
> who was calling you so you could "decide whether it's worth
switching
> to the other call."  My question is: how is this implemented.  I'd
> hate to think that I'm going to have a 1200 baud data burst come
> roaring over the line while I'm trying to talk.  Anyone know
anything
> more about how this?

In Caller ID on Call Waiting (CIDCW), the user is informed of the
incoming call via an alerting signal. This alerting signal is composed
of the Subscriber Alerting Signal (SAS -- this is the call waiting
beep)
and a CPE Alerting Sequence (CAS). If your CPE replies with a DTMF D,
it is CIDCW compatible. If your CPE replies with DTMF A, then it is
both CIDCW and ADSI compatible.

So, if you have a Caller ID box which is CIDCW compatible, it will
mute your handset and reply with a DTMF D. (The switch will mute the
far-end's voice path before sending the alerting signal, so the caller
won't hear all this.) Once the switch receives your ACK, it will
transmit the CID info and will restore the far-end's voice path. Your
CPE is expected to restore your handset operation.

If your CPE does not ACK within some period of time, the switch will
restore the far-end's voice path, NOT deliver CID information, and
will proceed like normal call waiting.


Tony Chor   Microsoft Corporation
Program Manager, Telecom Product Unit

------------------------------

From: [e-mail] (Carl Oppedahl)
Subject: Re: Information Wanted: Pulse Rate in India
Date: Mon, 19 Dec 1994 23:00:49 GMT
Organization: Oppedahl & Larson


In article <[e-mail]> [e-mail]
(M.A. Kumar) writes:

> I am setting up a modem for a friend of mine in India and the
> initialization requires the selection of proper pulse rate. Can
> someone tell me from the following three which one is correct for
> India:

> 1)      make/break ratio of 39% / 61% and 10 PPS (USA/Canada)
>         [DEFAULT SETTING]
> 2)      make/break ratio of 33% / 67% and 10 PPS (UK/Hong Kong)
> 3)      make/break ratio of 33% / 67% and 20 PPS (Japan).

It depends on the central office.  The correct answer might differ
from one central office to the next.

Have you tried the three choices?  If so, what results did you get?

Are you sure you can't use touch tone?

I would try 3, because if it works it will dial your numbers very
quickly.

If not that, then try 2, given India's historic ties to the UK.  Then,
if not
that, then try 1.


Carl Oppedahl
Oppedahl & Larson, patent law firm
[e-mail]

------------------------------

From: [e-mail] (S. Bapat)
Subject: Re: Cellular Roaming in New York Suspended
Date: 20 Dec 1994 04:08:50 GMT


[e-mail] (Paul Beker) writes:

> The ESN problem is a much, much bigger issue that won't be solved
> anytime soon, in the U.S.  My solution?  Move to an intelligent
> cellular architecture (ala GSM, or GSM-like), which actually
contains
> hooks and facilities to begin to address this issue.  Any algorithm
or
> validation scheme is beatable, but one of significant complexity
would
> certainly turn away the vast majority of the "crooks" ...

Random, idle, blue-sky thought: could be possible to use a challenge/
response authentication model for cell phone security, using perhaps a
public-key/private-key encryption scheme based on PGP or RSA (or a
digital signature mechanism)?

For example, each cell phone could have a really long (e.g. 1K)
private key burned into EPROM. When it first sends out its ESN, the
base station would look up the ESN its database and send out a
challenge bit pattern, which could only be decoded with the private
key in the cell phone.  The call would only proceed if the cell phone
responds to challenge successfully.

Compared to the cost of the cell phone, the cost of adding a 1K or 2K
EPROM would be marginal.  In the event that the cell phone's security
is compromised (e.g. someone records both your ESN and your cell
phone's response to the challenge and uses both to spoof you), you
could take it in to a branch office and have the EPROM reprogrammed
with a new private key.

Call setup times would be a couple of seconds longer (due to the
overhead of an extra database lookup) but quite possible many users
would accept this considering the benefits involved.


Subodh Bapat    [e-mail]

------------------------------

From: [e-mail] (Alain Fontaine)
Subject: Re: Handshaking: Computer-Computer or Modem-Computer?
Date: Tue, 20 Dec 1994 03:13:05 +0100
Organization: Universite Catholique de Louvain


In article (Dans l'article) <[e-mail]>, martyj@
mrcnext.cso.uiuc.edu (martin johnson) wrote:

> Is handshaking, ie xon/xoff or RTS/CTS, just between a computer and
> its local modem or is it passed on to the remote modem and remote
> computer? Can a modem whose RTS goes low, pass the fact of that
event
> to the remote modem by sending a Xoff? If a remote computer sends a
> Xoff thru its modem, and my local modem receives it, will it lower
CTS
> if xon/xoff is disabled?  Any enlightenment is appreciated. Ive been
> using and setting up lots of communications equipment for at least
ten
> years, and just realized that I dont know the answers to the above!

Things have changed a lot in ten years. Ten (mmm, let's say fifteen to
be sure) years ago, modems were just that: boxes containing a
modulator and a demodulator, with sometimes a few additional circuits
like a relay to connect the modem to the line and a ring detector. The
data communication interfaces we are still seeing today were invented
at that time, and their purpose was to allow the host to exercise a
direct and detailed control on those simple electronic functions. If
dialing by the computer was needed, one had to add another box, with a
second (parallel) interface to the computer.

Then came the era of 'intelligent' modems. The box called 'modem' now
contains, besides the electronic circuits performing the base
functions, what can be described as a computer. This computer
controls the electronic functions of the modem, and also performs some
new functions like error correction and data compression. So the
nature of the interface between host computer and modem has changed:
it is now rather a computer to computer link. Since there is a
computer in the modem itself, the way it reacts to interface signals
and/or particular values in the data depends on the way the (modem)
computer is programmed. The user has some control on its behavio(u)r
by means of the various at commands and s registers.

When data correction is used, the computers inside the modems use a
sophisticated protocol between them. This protocol allows (of course)
the transport of user data, with full error correction and
'transparent'
flow control. On each end of the link, a flow control mechanism may be
used between the computer in the modem and the host computer. A
different mechanism may indeed be used at each end of the link: the
computers in the modems are doing the necessary 'translation'. It all
depends on the way the modems are programmed.

------------------------------

End of TELECOM Digest V14 #459
******************************